Tuning or optimizing a machine for optimum performance is one of the first things many people think about when they install a new operating system. After they get all their applications installed and check out some of the new utilities, they want to see just how much they can get out of their new toy. The first thing you need to consider when reading this chapter is what tuning means. Getting every last ounce of power out of a system to perform a specific task represents one type of tuning. Allowing a system to perform a variety of specific tasks simultaneously (multitasking) is another. General tuning to provide the best performance in a variety of situations is yet another. I could go on. The fact of the matter is that there's no default configuration and no standard machine. All users have different needs and different hardware they need to use to get the job done. Any form of worthwhile optimization will take your specific needs into account.
I won't tell you how to tune your specific machine in this chapter. There's no way I can provide step-by-step tuning instructions for anyone without knowing his or her situation. What I will provide you with are some guidelines and tips you can use to create your own solution. You'll need to decide which tips you should implement and which you should ignore. I plan to provide tips for a variety of machine configurations, and your machine will appear somewhere in the list.
So, do you start reading right this second and hope to find the tips you need the first time through? You probably won't. It takes a bit of time and patience to really tune a system for optimum performance. To get some idea of what I'm talking about, consider race car drivers. A race car is tuned to fit its particular "personality." The mechanic and driver work together to come up with the best configuration for that particular car. In addition, the car is tuned to fit the track that it will race on and even the weather conditions. Tuning the car is probably the easy part of the process. Planning how to tune it requires a bit more effort.
You won't need to worry about the weather when tuning your system, but many other principles do apply. Planning how you need to tune your system is always a good idea. Just like any other worthwhile endeavor, tuning your system requires that you create a few goals and take a few potholes into account. Your machine contains hardware from a variety of sources. It probably contains a combination of components that are unique within your company. You need to consider how that hardware will react. Your applications are unique. Even if your job isn't unique, your way of doing that job probably is. A system that's perfectly tuned for the way I work probably won't do a lot for you.
Looking Ahead: This chapter takes a look at the physical tuning of your system. We'll look at other aspectssuch as tuning your desktopin other chapters. Physically tuning your system is an important first step. After you complete it, read the rest of this book (especially Chapter 2) for additional ideas on ways you can improve the efficiency of actually using your computer.
Keeping these personal needs in mind, let's look at some of the things you should consider before you start tuning up for the big race. The following list provides criteria you must consider before you start to tune your system. Of course, the time and effort you expend in this effort is directly proportional to the amount of performance you can expect to receive.
Peter's Principle: Stretching Your Hard Drive
Making your hard drive hold more has become a major topic in the wake of today's mega-application. (Doesn't it always seem to come down to the size of your hard drive and/or system memory?) Talk to just about anyone, and the first thing he'll suggest to make your hard drive hold more information is disk compression. That's a good idea in some circumstances, but in others, it could prove problematic. Some systems just don't compress all that well because of conflicts with the hard drive or controller. Other people worry about the reliability of disk compression, so they don't use it. Still another problem is the type of data your machine contains; application code doesn't compress all that well. If you store your data on the network, your machine probably won't make the best candidate for compression.
Several other ways you can extend your hard drive cost a bit but provide long-term benefits. The first is to buy a good CD-ROM. I'm not talking about an older double-speed model, but a high-end, quadruple- or sextuple-(6X) speed drive. (NEC just introduced its new 8X drive; other vendors are sure to follow.) Make sure that it is connected to a good controller and that you have a separate hard drive extension. A few controllers actually limit throughput to the speed of the slowest device in the chain. Placing the CD-ROM on a separate chain ensures that you won't adversely affect the speed of higher-speed devices. Many vendors such as Corel Systems and Microsoft are making their applications so that you can copy a few files to the hard drive but run the application from the CD-ROM. Not only does this save hard drive space, but it also allows you to install the full capabilities of a product. You'll pay a performance penalty for using this type of installation, so you'll want to reserve it for applications you don't use on a daily basis.
Another disk space saver is to use compressed file formats whenever possible. This is especially true in the multimedia and graphics areas. A CorelDRAW! file that consumes a mere 60KB in its native format could consume 1MB or more in Adobe Illustrator (AI) format. Another example is the PCX format. Storing a 1024x768, 16-color image requires 90KB. That same image requires 200KB if you increase the number of colors to 256. Storing the same 256-color image in TIF format (using LZW compression) uses 136KB and only 124KB in GIF format. As you can see, something as simple as a file format can make a big impact on the amount of space available on your hard drive.
After you get your hardware configuration out of the way, it's time to consider your software configuration. Windows NT does a much better job of managing resources than Windows 3.x did, but it's by no means perfect. Windows 3.x's infamous system resources problem is still with us. You still have the same problem with the 64KB USER and GDI areas. Filling these areas with icons, windows, and other graphical elements still results in a system that runs out of memory before physical memory is exhausted. (We'll see later that there's a lot more than meets the eye to the whole topic of system resources under Windows NT. Microsoft has tuned this operating system to make many of the problems you experienced under Windows 3.x disappear.) The way in which Microsoft configures and uses memory now, however, really reduces the drag you will see as system requirements increase.
Under Windows 3.x, I'd start to run out of resources after loading my word processor, spreadsheet, communications program, and one or two small utility programs such as a screen saver or Notepad. I usually consider closing an application or two when I get to the 35 percent system resources level, which is about where I was with this configuration. Windows NT still has 78 percent of its resources free when using the same configuration. This means that I can usually open two or three more applications on top of my usual configuration.
Of course, system resources are only one memory factor. There's the actual level of RAM to take into consideration as well. Under Windows 3.x, you would start to notice a fairly large performance penalty when you got to the point where the swap file was as large as real memory. Under Windows NT, this doesn't seem to be as much of a problem, but it's still very noticeable. The bottom line is that if your swap file starts approaching the size of your installed memory, it's time for an upgrade.
You need to take into consideration the combination of system resources and system memory when thinking about your software situation. A memory-constrained system always lacks enough memory to perform the job you need it to. It's a subjective type of measurement based on how you actually use your system. You should load the Resource Monitor (discussed in Chapter 2) and, over a few days, track both the size of your swap file and the number of resources you have available. If you start to see a pattern of low memory, read the next section. You might even find that the problem isn't the amount of installed memory on your machine but the way you use that memory.
Windows NT users have a plethora of other concerns that other Windows users don't share. For one thing, the platform you choose can make a great deal of difference. Even if you choose an Intel platform, however, you need to consider some of the advanced capabilities that Windows NT provides. You can get over part of the performance hurdle, for example, by using a multi-processor machine. There's also the availability of multiple hard disk formats to consider. An NTFS partition may reduce flexibility (because you can only access it from within Windows NT), but it also enhances performance.
By now, you can see what all this preliminary checking is leading to. A mechanic would never consider tuning a car before checking it over for the first time. Likewise, you should never consider tuning your system before you know what type of system you have and how you use it. It's not enough to say that you have 24MB of RAM installed. The way you use that RAM determines whether it's sufficient. A 1GB hard drive might sound impressive, unless you're trying to create a lot of multimedia presentations with it. Then this'll sound like a rather paltry amount. (I've seen some multimedia systems that have 4GB of storage, although that's by no means standard.)
Memory would seem to be the biggest problem most people face on a system, but it really shouldn't be. I recently looked at memory prices at my local parts store and found that I could buy an 8MB SIMM for a mere $320. I'm almost positive that isn't the cheapest price in town, either. Although memory isn't free, it certainly isn't the most expensive upgrade you can make to your system. Few new items can provide as much potential for a noticeable increase in system performance as memory.
Microsoft will try to tell you that you can get by with as little as 12MB of RAM when running Windows NT (the Workstation versionthe server version requires 16MB minimum). I wouldn't believe this if I were you. The minimum I recommend is 16MB, and that's if you intend to run only two or three applications at a time. Just think about these numbers for second. How many of you can say you run a single application? No one? I thought so. Think about how many applications you do run. At the very least, you'll probably find four or five applications running on your machine. Make sure that you include small applications like e-mail in the count. A more reasonable system will contain 32MB of RAM. Even with 32MB of RAM, I find my system a tad constraining at times. Of course, the opposite extreme exists as well. Few people I've talked to report any noticeable improvement in system performance after they exceed 128MB, although that's probably not due to any lack of effort on the part of Windows NT. Currently, a system with 32MB to 64MB is probably the maximum you need.
Suppose for the moment that your boss absolutely won't buy any additional memory for your machine and you're stuck at that 12MB level. What can you do to improve the situation? How can you stretch 12MB of RAM enough to make your single-tasking system (from a memory perspective) work as a multitasking system?
Tip: The generic optimization techniques in this section work equally well with Windows 95, WFW 3.x, and Windows 3.x workstations. If you're using Windows NT in a peer-to-peer LAN environment, it's very likely that you'll use a Windows NT workstation (or the server version) as your file server. You also might have some older machines that still use WFW 3.x connected to the network. Whatever your setup, these generic tips can help just about any workstation make better use of the memory it contains.
There are a few quick and easy methods I recommend that you start with. Anyone can use these methods, but using them always involves some level of compromise that you might not be willing to make. The following list shows my quick fixes to memory problems:
Now that we've gotten past the generic tips, let's look at a few Windows NT-specific ways to enhance overall system performance and the amount of memory you have available. Unfortunately, none of these tips will work for Windows 3.x systems. Even though many might work with Windows 95, you'll want to give them a long test before making them permanent. Some of these tips are Windows NT 4.x-specific; don't try using them with older versions of the product because you won't get the desired results.
Peter's Principle: Efficiency of Actions Versus Memory Usage
Something I'm discovering under Windows NT is that efficiency in action is sometimes accompanied by some decrease in memory usage. The Windows NT interface seems to be designed to make every movement as easy as possible (although some users still find it difficult to use).
Using features such as a context menu might not seem like a very big dealyou save only two or three mouse clicks in most casesbut they result in memory savings. Windows NT provides other speed-enhancing features that save you memory. Using the automatic settings for most of the system parameters such as virtual memory, for example, improves performance and enhances memory usage.
Some Windows NT features aren't only extremely efficient, but also save you a considerable amount of time. You'll find that using Explorer costs you a lot less memory compared to using Program Manager, for example. (A comparison on my machine shows system resources at 98 percent when using Explorer but only 87 percent when using Program Manager in the same configuration.) You can check this out on your machine by changing the shell=Explorer.exe line in SYSTEM.INI to shell=Progman.exe and then shutting down and rebooting your system. Using the Explorer interface is so much more efficient that I would never go back to Program Manager.
At times, Windows NT does a less-than-perfect job of setting up your machine. Earlier, I mentioned that you should remove any unneeded drivers. What would happen if you had some "hidden" drivers you really didn't need installed on your system? Figure 3.1 shows a dialog box that illustrates this point perfectly. I installed Windows on a machine in a peer-to-peer networking environment. The installation program even asked about the level of support I wanted when I got to that point in the installation. It assumes that not everyone knows what they're talking about, however, so it installed both Microsoft and Novell support on my system. The Novell support goes to waste because this is a peer-to-peer network that doesn't connect to a NetWare file server. I have a Windows NT server, a Windows NT workstation, and a WFW 3.x machine all connected and sharing resources.
Figure 3.1. Sometimes Windows NT installs too much support. You can reduce your memory footprint and improve performance by getting rid of this additional support.
You need to look at three steps in this particular situation:
Tip: If you remove one of the protocols from your workstation and find that you can't connect to the other workstations, make sure that all the workstations are using the same protocol. Many people find that working networks suddenly fail when they try to optimize their setup. This simple fix of checking for network protocol consistency repairs the vast majority of "broken" installations.
Looking Ahead: Chapter 21, "Peer-to-Peer Networking," talks about peer-to-peer networks in detail. Likewise, Chapter 22, "Client/Server Networking," talks about client/server networks in detail. These two chapters will tell you about the mechanics of your network connection. You should also spend some time reading Chapter 23, which talks about security issues. You have to weigh the reliability and flexibility of your network connections against the need to save memory.
DOS applications represent a big challenge under Windows 3.x. I'd love to say that Windows NT will run every DOS application you ever owned without any major configuration problems, but that wouldn't be very accurate. In fact, if you're going to run a lot of DOS applications, Windows NT isn't even the best operating system you could choose. The bottom line is that Windows 95 runs these older applications far better than Windows NT or Windows 3.x. If you only plan to run a few well-behaved DOS applications, however, Windows NT can still get the job done. It's best to remember that you will encounter problems when running certain DOS applications, and you need to tune your system to avoid them.
The good news is that you can make all the required changes using the application's Properties dialog box. Windows NT supports all the old configuration features provided by Windows 3.x and adds quite a few of its own. This means that you can make the required changes by right-clicking the object and choosing Properties from the context menu. The first thing you'll see is an <Application> Properties dialog box similar to the one shown in Figure 3.2. Everything you need to run DOS applications efficiently under Windows NT appears in this dialog box. It replaces the PIF Editor used in previous versions of Windows.
Figure 3.2. The <Application> Properties dialog box.
There are many similarities between the entries you'll find in the Properties dialog box and those in the PIF files of previous versions of Windows. Don't be fooled. Windows NT provides much the same functionality as those previous versions; it just makes it a bit easier to change the settings. Fortunately, the Properties dialog box does add some much-needed fields and a new mode or two.
Several tabs directly affect the way a DOS application behaves under Windows NT. The first one we'll look at appears in Figure 3.3. The Program tab contains some fields that tell Windows NT what application to run and where to run it. This includes the application name and its working directory. The area of concern for this chapter is the Windows NT button near the bottom of the dialog box. Clicking that button displays the Windows NT PIF Settings dialog box shown in Figure 3.4, which contains some of the DOS-specific settings that affect how Windows NT will react.
Figure 3.3. The Program tab of the <Application> Properties dialog box.
Figure 3.4. The Windows NT PIF Settings dialog box.
You only get a few tools to run DOS applications under Windows NT. The fact that you can choose a special AUTOEXEC.BAT and CONFIG.SYS file to run a troublesome application certainly helps. You'd place the name and location of those files in this dialog box. This particular feature helps you run two categories of DOS applications. The first category is game programs. Using special AUTOEXEC.BAT and CONFIG.SYS files can make a big difference. Even this advantage won't allow you to run an ill-behaved DOS application, however. Notice the Compatible Timer Hardware Emulation checkbox. I usually select this option for games as well, because many games use timing loops rather than interrupt-driven programming techniques to keep game components in sync. Unfortunately, checking this box also involves a penalty. Running an application that has this box checked usually wastes processor cycles, because Windows NT must spend additional time processing the application's needs.
The other categorystrangely enoughis older graphics applications. Using tuned AUTOEXEC.BAT and CONFIG.SYS files can help these applications use system memory more efficiently and run better in most cases. The old copy of Harvard Graphics I had lying around performed almost twice as fast using hand-tuned files as it did using the default files shown in Figure 3.4, for example. After a bit of research, I concluded that this was due to a combination of factors, such as direct-screen writing and other rule-breaking behaviors that create problems for these applications. I'd still say that this is the exception to the rule. The best idea is to check out an application using the default files first; creating hand-tuned files is a very time-consuming and resource-wasting endeavor. Better yet, replace it with a Windows NT-specific product if at all possible.
The Memory tab, shown in Figure 3.5, can also help you obtain the best possible setup for your application. In most cases, you'll want to stick to the Auto setting. However, I have several applications that require more environment space than the Auto setting provides. All you need to do is adjust the setting of the drop-down listbox as required. The same thing holds true for any other memory settings you might need to adjust.
Figure 3.5. The Memory tab allows you to customize the DOS application's memory settings.
There's one thing you should always keep in mind with this tab. Setting any memory entries you don't need to None will save system memory and allow Windows NT to provide better services to the rest of the applications on your machine. Windows NT always assumes a worst-case scenario with DOS applications; setting the various memory options gives it a little more information to work with.
The Protected checkbox in the Conventional Memory group is a two-edged sword. Setting it will allow some applications to run. It will also prevent Windows NT from moving applications around in memory. Some applications that access memory directly need this kind of protection. The down side of checking this box is that a fixed session in memory always increases memory fragmentation and the chance that you'll artificially run out of memory.
The last tab we'll look at from a performance perspective is the Screen tab, shown in Figure 3.6. We'll talk about only two checkboxes in this chapter; the rest are covered in Chapter 13, "Exploiting Your Software." Not surprisingly, both checkboxes appear in the Performance group.
Figure 3.6. The Screen tab provides two performance settings.
The Dynamic Memory Allocation checkbox is the important one here. As with the Protected checkbox on the Memory tab, this checkbox determines whether Windows NT can move memory around. Here's the problem. Many graphics applications resort to using direct screen writes to get the performance they need. Those same graphics applications won't work under Windows NT if you keep this box checked, because Windows might move the "virtual" screen that the application is actually writing to somewhere else. The warning sign you need to look for on a graphics application is some type of distortion. Most applications display vertical bars or some type of striation. You might see part of the display shift or what appears to be cursor trails on-screen. All these types of distortion tell you that you need to uncheck the Dynamic Memory Allocation checkbox.
Another group of applications somewhere (I've yet to find it in my office) needs to directly access the ROM routines. The Fast ROM Emulation checkbox tells Windows NT to emulate the display ROM in fast protected-mode RAM. If your application is looking for the system ROM in conventional memory, however, it won't find the emulated version. One way to tell whether your application needs to have this box unchecked is if you get unexplainable system crashes that you can't pinpoint to another cause. These crashes could be caused when the application looks for ROM code at a certain address and doesn't find it.
Getting more than one application to run on a system at the same time usually involves making some compromises. You can tune a single-tasking system to provide the best performance for that one application. You could tune your system in such a way that a disk-intensive application gets everything it needs in order to get the job done quickly, for example. But what happens if you run one application that's disk-intensive and another that's CPU-intensive? Do you starve the resources of one to get better performance from the other?
We've already looked at most of the generic ways to provide additional memory. This is one area you'll need to concentrate on if you plan to multitask. Running more than one application at once always consumes a lot of memory. What you might not realize is that your performance levels might become artificially low because of the way in which Windows NT handles memory management.
Disk swapping, the same feature that provides so much virtual memory for your applications, can also wreak havoc in a multitasking environment. Two big clues tell you when disk swapping has become a problem and not a cure. First, you'll notice a dramatic increase in your system's disk activity. This isn't always a bad thing under Windows NT, but it is an indicator. Windows NT uses a very aggressive disk-writing algorithm to make the most of system idle time. You might see what seems like a lot of disk activity, when all Windows NT is doing is writing some of the data from memory to disk.
The second clue will tell you just how bad the memory situation is. Look at the size of your swap file. If your swap file is about the same size as your real memory, your system is memory-starved, and you really can't run the number of applications you're trying to run. Windows NT will try its best to provide a satisfactory level of performance, but the truth is that you just won't see it.
There are far more scientific ways to precisely measure system performance, and we'll look at them in the next section. The two clues we just discussed provide you with a very quick idea of what your system performance is like right this minute without wasting a lot of your time trying to define it completely. Of course, using Performance Monitor to display your actual system performance for your boss could get you the memory upgrade you've been wanting.
You'll also want to take into account the needs of the LAN as a whole if your system doubles as a file server. A peer-to-peer network depends on the resources of one or more workstations to act as file and print servers. This doubling of tasks is really another form of multitasking. You might run only one or two tasks on your machine, but it'll run very slowly if you don't take into account the needs of other people who are using your system. In this case, however, a simple look at the swap file and disk activity probably won't provide you with enough information. You'll have to monitor the network statistics using the Performance Monitor program.
Windows NT also provides another utility (actually, a Control Panel applet) that will come in handy here. The Server applet (described in Chapter 21) provides information about who is logged in and what type of resource they're using. You can combine this information with that obtained from Performance Monitor to create a clear picture of how your machine is being used in the network environment. Figure 3.7 shows a typical example of the type of information you can expect. Making a correlation between who is using which resource and what the level of activity is might seem like a difficult task, but after a while, you'll notice certain patterns emerging. You can use those patterns as basis for tuning your system.
Figure 3.7. The Server applet allows you to monitor who is sharing your computer and which resources they're using.
Load balancing was a term I thought I'd never have to apply to a PC, but here it is. You can get better performance out of your system if you balance the types of tasks it performs. Scheduling all your disk-intensive tasks to run at the same time is one sure way to bring your system to its knees. Likewise, scheduling all your CPU-intensive tasks at the same time will garner the same resultsonly faster. If you're working on a spreadsheet in the foreground, that might be a good time to compile an application or perform some database-related task in the background. Of course, the opposite is true as well. You can always perform that really intense spreadsheet recalculation in the background while performing data entry in the foreground.
Tip: Unlike previous version of Windows, Windows NT actually does a reasonable job of downloading files and performing other forms of on-line communication in the background. I recently spent almost eight hours downloading a new copy of some Windows NT files from the Internet at 28.8 Kbps while working on articles and my spreadsheet in the foreground. I never did miss a file or experience any form of corruption. Under Windows 3.x, I would've had to give up my system for the day in similar circumstances. One rule of thumb you need to follow is to keep resource-hogging, 16-bit applications to a minimum. Windows NT does a good job of handling short delays without losing characters. Some older applications, however, grab the system for so long that background communications are impossible even with the improved features that Windows NT provides.
There's one final consideration you need to think of when you want to get the most out of your multitasking environment. Using 16-bit applications under Windows NT means that you must suffer the consequences of cooperative multitasking. In essence, a program can be a bad sport and grab the system for a long period of time (fortunately, Windows NT maintains positive control of the system so that it can reduce the impact of this system-hogging behavior). 32-bit applications don't get this kind of treatment. Ready or not, they have to turn control of the system back over to Windows NT at specific intervals. The difference between multitasking 16-bit and 32-bit applications will absolutely amaze you. If multitasking is the name of the game, 32-bit applications are what you need to make it work smoothly.
Windows NT is a complex operating system, there's no doubt about it. A change that looks fine when you make it might cause unexpected results. You might remove a device driver that you think is no longer in use, for example, only to find that it really is being used by some part of the system. Windows NT does a good job of keeping you out of trouble for the most part, but it's not perfect.
There's a tool that can help you out, though. You can use the Event Viewer to keep track of the workstation as a whole (see Figure 3.8). Any events that get logged in here tell you something about your computer. There are security as well as other system events. I want to concentrate on those events that will affect your performance-tuning efforts in this section. We'll look at other event types as the book progresses.
Figure 3.8. You can use the Event Viewer to keep track of system events and monitor your system for any negative results from performance tuning.
You'll want to make sure that you're looking at the system log. Use the Log | System Log command to display it. There are two other logs: security and application, but we won't talk about them here. Now that you have the right log selected, look for any red stop sign (Error) icons. Those are the icons that tell you something is wrong in the system. Figure 3.8 shows several of these icons. In this case, I forced them to appear to show you what they look like. You'll notice two other icons here as well. The blue information icon simply tells you about a non-critical system event. For the most part, you can ignore these icons unless you want to track some specific system event. The warning icons (the yellow exclamation points) tell about a special event. In this case, Windows NT is turning on bus mastering support for my IDE controller. You'll want to check out these icons, but they're usually non-critical as well. Event viewer also supports two other icons, but we won't see them here: success audit and failure audit.
Obviously, the short descriptions shown in the Event Viewer window don't tell you enough to fix a problem. Select any of the lines and press Enter to see the Event Detail dialog box shown in Figure 3.9. Notice that it tells you exact details about what caused a particular event to happen. You can use this information to troubleshoot the problem. This dialog box doesn't tell you about the interactions that take place between system components, however. In other words, you may remove a much needed driver, but some other component will fail as a result. You might see the failed component in the Event Viewer and have to work your way back to the missing driver.
Figure 3.9. The Event Viewer provides detailed information about the cause of a particular entry in a log.
I use three methods to monitor the results of any optimization changes I make. The first is by looking at the Resource Monitor. Checking how much system resource memory you have left after an optimization is one way to see whether the change was effective. I also monitor the size of the swap file. Even though this isn't a precise measure of the state of system memory, it does provide an overall indicator of system memory. Windows NT increases the size of the swap file as it needs more memory, so checking on the size of the swap file is one way to see how much memory Windows NT needs over the physical memory available on the system.
The third method is an actual monitoring tool. Performance Monitor is an optional utility that you can install, and it's a very worthwhile tool. It allows you to track a variety of system statistics, including CPU usage and actual memory allocation. Monitoring these statistics will tell you whether a certain optimization strategy was successful. Performance Monitor also provides a means of detecting performance-robbing hardware and software errors on the system. Figure 3.10 shows a typical Performance Monitor display.
Figure 3.10. The Performance Monitor allows you to view system events and to monitor the effects of configuration changes.
When you start Performance Monitor for the very first time, you'll get a blank screen. Before you can do anything, you'll need to select some events to monitor. I decided to monitor CPU usage statistics for the machine I was testing. Figure 3.10 shows one way to display this information. There are four buttons on the toolbar that change the way you track information: Chart, Alert, Log, and Report. You can also use the View menu to change the presentation. I find that the chart presentation is the most helpful when I need to monitor system performance over a long interval. The alert presentation shown in Figure 3.11 comes in handy when I'm looking for a specific event to happen. You might want to reduce the network load on a particular machine, for example. You could use the alert presentation to display specific levels of machine overuse. The log presentation is the longest-term storage technique (see Figure 3.12). It helps me track trends in computer usage over a period of weekssomething you'll need to do to track some types of network problems. Unlike the other presentation types, you must select an entire object to log instead of specific statistics. (I'll tell you later how to display the contents of a log file on-screen.) The final view, report, is handy when I need to present my statistics to someone else or need a quick update for myself. You can see an example of this presentation in Figure 3.13.
Figure 3.11. The alert view allows you to detect specific events.
Figure 3.12. You'll find the log view handy for tracking long-term usage trends.
Figure 3.13. The report view is important when you need to share information with other people or give yourself a quick update.
Performance Monitor uses a default monitoring period of five seconds. This might not be fast enough in certain situations. If you're troubleshooting a bad NIC or you want instant feedback on a configuration change, you'll want to change this setting to a lower value. Likewise, if you're performing long-term monitoring, you might want to set it to a high value. Use the Options button within any of the views to change this setting. Figure 3.14 shows the dialog box that changes the interval for the chart presentation.
Figure 3.14. Short intervals aid troubleshooting efforts; long intervals help you monitor your machine's performance more accurately.
There's something else you should notice about this dialog box. It allows you to change the method of presentation. Each of the views that I described previously allows you to do this. In the chart view shown, for example, you can add both a horizontal and a vertical grid. The log view displays a modified File Open dialog box, which allows you to create a new log. The same dialog box allows you to start and stop log entries.
The second set of three toolbar buttons allow you to change the items Performance Monitor displays. Use the Add Counter button to add new items to the list. Figure 3.15 shows a typical Add to Chart dialog box. The other views' Add To dialog boxes work in about the same way as this one. You select an object like the processor to monitor, and then you select an instance of that object. In the case of a processor, you may only have one instance, but disk drives usually provide several instances. After you select an instance of an object, you can select one of the counters (the items that Performance Monitor will track). There are a few bells and whistles here as well. You can select a specific color and line width for your counter, for example. You can use the Modify Selected Counter tool to change the way Performance Monitor displays a particular value. You might want to display something in green rather than blue, for example. You can also change the upper limit of some values to provide a consistent range of values for particular items. Finally, you can use the Delete Selected Counter tool to remove an item from the monitoring list. Remember that the more items you display on-screen, the less screen area each item receives. This, in turn, limits the accuracy of the readings you'll take. Make sure that you monitor only the essentials. For that matter, you might want to break the items into groups and monitor a single group at a time.
Figure 3.15. The Add to Chart dialog box allows you to add counters for Performance Monitor to track.
Tip: Every counter addition dialog box contains an Explain button like the one shown in Figure 3.15. Click this button if you don't understand what a particular statistic is all about.
What types of things will Performance Monitor track for you? You can track everything from the number of bytes the disk writes per second to the number of times someone tries to access your machine from the network. Performance Monitor tracks a lot more items than I have room to talk about here, and Microsoft keeps adding more items with every version of Windows NT. In addition, there's no limit to the ways in which you can arrange the items you want to track. It's also important to note that you can track each resource (called an instance of an object) individually. This means that you can display the same statistic for each disk drive on your machine.
Let's look at one other item in our whirlwind tour of this particular utility. I mentioned earlier that you can create log files of counters that you plan to monitor over a long period of time. In reality, you have to store entire objects (and all instances of that object). You add objects to your log just like you would any of the other views I've talked about so far. You also need to select a log file and start the log to record any data. Figure 3.16 shows a typical Add to Log dialog box, which you access by choosing the Options | Log command or by pressing Ctrl+O. This is where you'll select the objects you want to monitor. Figure 3.17 shows the Log Options dialog box. This is where you'll enter the name of a file in which to store the data and actually start the recording process.
Figure 3.16. You can use the Add to Log dialog box to define the objects you want to log.
Figure 3.17. You can use the Log Options dialog box to start the actual data-recording process.
There are two buttons on the toolbar that I haven't talked about so far in this discussion. The Update Counter Data tool allows you to break the normal recording interval. Suppose that you get an alert and want to record system conditions at a specific time instead of waiting for the normal recording interval. Clicking this button updates all the counter values immediately. You can use this button in any of the four views, but it's most useful here.
The other button, Commented Marker, is just as handy. You can use this tool to add a commented marker to your log. I normally click the Update Counter Data button first and then the Commented Marker button. You'll see a dialog box asking you for a comment. Type a comment and click OK to make the addition permanent. You can add as many comments as needed to get the job done. I usually make mine short but very specific. I'll show you how these comments actually look in the log in just a few moments.
OK, so you've recorded a log and want to view the results in chart form. How do you do it? The first step is to click the Chart view button on the toolbar. Use the Options | Data From command to display the Data From dialog box shown in Figure 3.18. Notice that you can choose to view the current activity or the contents of a particular log. I recorded a log for this example, so I entered the name, selected the Log File option, and clicked OK. The first thing you'll notice is that the chart display is static instead of constantly updated. You'll have to add your counters back in because Performance Monitor will erase them.
Figure 3.18. You can use the Data From dialog box to view data you recorded in a log earlier or to view the current activity.
Now that your recorded counters are displayed, let's look at another important feature of Performance Monitor. If you're recording data for days or even weeks, you won't want to look at all the data in one big lump. Wouldn't it be nice if you could look at just a small piece of it? Performance Monitor allows you to do just that. Choose the Edit | Timeframe command to display the Input Log File Timeframe dialog box shown in Figure 3.19.
Figure 3.19. You use the Input Log File Timeframe dialog box to select a subset of the data you've recorded for display.
This dialog box contains two main areas. The first area contains a timeline. You can see the start and end of the recording period, along with the start and end of the display period (the data you'll actually see on-screen). Notice that there are what appear to be buttons or bars at either end of the timeline. If you move these bars, you'll change the starting and ending time of the data that you'll actually view on-screen. Changing these bars also changes the position of two gray lines on the chart. The lines show you where the data display will begin and end.
Look at the area below the graphical time display. Performance Monitor always places one bookmark in the file for you. The bookmark tells you when the recording period started. Notice that there's a second bookmark listed in Figure 3.19. This bookmark is the one that I added earlier. Highlighting a bookmark and then clicking the Set as Start or Set as Stop button moves the buttons in the timeline display. You can use this as a method for finding specific areas of your log file.
Practice creating long file names that a DOS or Windows 3.x user can understand. Use Explorer to create a new file in a temporary folder and give it a long file name. Then open the DOS prompt and view that same file name. Does the name make sense in both contexts? If not, you'll need to spend a little more time working on this. Remember that you're effectively reduced to six characters for the file name because of the way that Windows NT differentiates between different files with similar long file names.
Spend some time learning to use the Event Viewer. What kinds of events does your system appear to monitor as a default? Do you see any events that require your immediate attention? How do the Event Viewer entries help you diagnose problems?
Learn to use the Performance Monitor as both a diagnostic aid and a tuning tool. What type of setup helps you most when it comes time to tune your system? Make sure that you try various setups to perform specific kinds of tuning. You'd want to monitor disk statistics when tuning your hard drive, for example, and network statistics when monitoring your connection efficiency. Likewise, what setup works best for various types of diagnostic situations?